上一篇 Day12 把這個專案的 IAM 兩層身份都查了一次，收尾留了一個問題：**就算權限都對了，Lambda 真的在雲端跑起來之後，出了狀況要去哪裡看？**這篇要接的就是這一段。

寫程式的時候，我們很習慣一件事：程式碼出錯，終端機或瀏覽器 devtools 立刻跳出紅字。但 Lambda 不是跑在你的電腦上——它是在 AWS 某個你看不到、摸不到的機器上被短暫喚醒執行，執行完畢環境可能就被回收。沒有一個「你正在看著」的終端機視窗，錯誤要去哪裡才能看到？

答案是 CloudWatch——AWS 幫每一支 Lambda 自動接好的監控中樞。

🧱 地基概念

CloudWatch 其實是三個東西的合稱

這個專案目前只用到 Logs——規模小、流量幾乎是零，Metrics 跟 Alarms 還用不太到，但值得知道它們的存在。

Logs 是怎麼「自動」出現的？

好消息是這一塊幾乎零設定：Lambda 執行時，你程式碼裡的 console.log（或任何寫到標準輸出的內容），AWS 會自動幫你收進 CloudWatch，不用額外接第三方服務、不用自己寫上傳邏輯。

這些 log 被歸類在一個叫 Log Group 的地方（這個專案裡是 /aws/lambda/函式名稱），每一次 Lambda 被呼叫執行，那一次的 log 會被歸進一個獨立的 Log Stream——所以「一次 Lambda 執行」大致對應「一段 Log Stream」，出問題時要找的就是「那次請求對應的那一段」。

🔧 實際操作

實際上怎麼查

最直接的方式是 AWS CLI 的 aws logs tail：

aws logs tail "/aws/lambda/函式名稱" --follow

--follow 會像 tail -f 一樣持續盯著新進來的 log，適合一邊測試、一邊即時看執行狀況。不想用指令列，AWS Console 裡的 CloudWatch → Log Groups 也能直接點進去用網頁介面瀏覽，效果一樣，只是比較適合事後回頭查特定一次的紀錄。

小結：Part 3 到這裡，一個完整的後端骨架搭好了

雲端開發把「哪裡出錯」這件事，從「盯著螢幕看例外訊息」變成「去對的地方查對的 log」——地方對了，錯誤其實不難找。

串起 Day10~13 回頭看：後端邏輯放上雲（Lambda）、接上外部入口（API Gateway）、拿到執行其他服務的權限（IAM）、出事有地方可以查（CloudWatch）——一個完整、能被外部呼叫、能被追蹤的後端骨架，就這樣搭起來了。下一部分要開始讓這個後端真正「聰明」起來——接上 AI。